Within the framework of the 3GPP project (“Third Generation Partnership Project”), a new telecommunications network architecture called IMS (“IP Multimedia Subsystem”) has been proposed.
This new architecture allows operators of this type of networks to offer new services to different types of users (fixed or mobile), while still being compatible with the telecommunications networks of earlier generations.
Thus, the new-generation networks must be able to implement communications of very different types according to the case in point.
To this end, when a user registers with the telecommunications network, the 3GPP standard proposes to identify the user as well as a list of characteristics linked to this user, and to select network resources accordingly in order to prepare for subsequent implementation of communications.
A brief description of this selection as recommended in documents TS 23.228 (section 5.2.2.3) and TS 24.229 (section 5.3.1.2) of the 3GPP standard is given with reference to FIGS. 1a and 1b. 
FIG. 1 is a protocol sequence diagram showing the exchanges between a user device 100, an access unit 101 of the P-CSCF (“Proxy-Call Session Control Function”) type, a query unit 102 of the I-CSCF (“Interrogating-Call Session Control Function”) type, an authentication server 103 of the HSS (“Home Subscriber Server”) type, an address server 104 of the DNS (“Domain Name Server”) type, and a service unit 105 of the S-CSCF (“Serving-Call Session Control Function”) type.
When the user device connects to the telecommunications network, it issues a registration request 106 to the access unit 101 in order to be identified on the network. The access unit 101 acts as an input point on the network for the user device. Next, the access unit 101 transmits the request to the query unit 102 which will take responsibility for identifying the service unit 105 which will process this registration request and manage the user's communications.
To this end, the query unit 102 issues an identification request 107 to the authentication server 103. The authentication server 103 then verifies if the user is already registered or not and if the user is already associated with network resources or not.
The case where the user is not registered is discussed herein.
The authentication server 103 then selects a service unit 105 to be assigned to the user device for the communication and next delivers an identifier 108 called FQDN (“Fully Qualified Domain Name”) to the query unit 102. This identifier represents a symbolic address on the network of the service unit 105 to be assigned to the user.
The query unit 102 then interrogates the address server 104, sending the request 109 comprising the FQDN in order to know the physical address (IP address) of the service unit 105 based on the FQDN. The address server 104 provides in response the physical address 110 of the service unit 105.
The query unit 102 then transmits the request 106 to the service unit 105, which takes responsibility for authenticating the user to the authentication server 103. Next, the service unit returns a registration acceptance message 111 to the query unit 102 which transmits it to the user device via the access unit.
A further example of registration is now described, with reference to FIG. 1b. FIG. 1b repeats the different elements described with reference to FIG. 1a, and the registration starts in the same way as previously, until the authentication server 103 receives the identification request 107.
This time, instead of selecting the service unit and sending a symbolic address of the latter, the authentication unit sends to the query unit 102 a list 112 of characteristics attached to the user profile. These characteristics are also called “capabilities” in the above-mentioned standard.
On receiving the list of capabilities, the query unit selects a service unit compatible with the capabilities in the list. The query unit then sends the request 109 to the address server in order to know the physical address of the service unit selected based on its FQDN.
The address server then returns the physical address of the service unit and the registration continues as described previously.
The selection of the service unit as recommended in the standard cited above presents a certain number of problems.
The operator must associate a group of service units with each symbolic address. Thus, once the query unit has chosen a FQDN, it only receives the physical address of the associated service units. This limits the final choice of the service unit to be used, and prevents the best choice being made, for example if the service units associated with the chosen FQDN have a load level that is too high. The association initially set by the operator fixes once and for all the service unit choice strategy to be used.
The selection of the service unit therefore lacks flexibility, and does not always allow the best choice.
Moreover, it is the query unit that makes the choice of the service unit based on capabilities. Thus, the operator must ensure that all the query units of the network have an updated list of all the capabilities of the network, all the service units of the network, and all the correspondences between these service units and these capabilities.
Managing the network thus remains complex for the operator.